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Abstract 


for the standardization state and status of this protocol. 


This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in TCP/IP based internets. 
In particular it defines objects for managing MAC bridges based on 
the IEEE 802.1D-1990 standard between Local Area Network (LAN) 


segments. 


Provisions are made for support of transparent bridging. 


Provisions are also made so that these objects apply to bridges 
connected by subnetworks other than LAN segments. 


Table of Contents 


WWWWWWWWWWN)D EF 


NNNPRPRPRPHE BE 


Decker, 


Ow WN 


The Network Management Framework ... 
Objects 
-l Format of Definitions ............. 
Overview 


.1 The dotidBase Group ............. 
The -dotldStp Groupe sensie eaea 
The dotLdSr Group™ sasea doan 
The: dot lal pr Groupe sese eee age Si se 
The dotldStatic Group ........... 


Relationship to Other MIBs ........ 


Langille, 


.1 Relationship to the ’system’ group ................. 
-2 Relationship to the ’interfaces’ 


Rijsinghani & McCloghrie 


ADNDDDAAAHADWWWNND 


GEOUP) gio «eth ha es 


[Page 1] 


RFC 1493 Bridge MIB July 1993 


S03 Textual Conventions io dewh ee ie eee Sse ee es oe eee E oe ed 8 
4:..-Changes: from REC L280 ceed egg esa ded ces ak cow ahd Boer od Blo eld 8 
Din MS EAT ET OMS se wid ay areas N ra a eer a as ah utter E T e 0s ee ache ole ei ty 9 
5k) GROUPS: inthe Bridge MIB oea e-kde oe eek he hese cod a a Ress t1 
5.2 The dotldBase Group Definitions ......s.ssssssssseseses es FE 
5.3 The dotldStp Group: Definitions Sareea ei e e ae we, hee end 14 
534 The dotldlp Group: Definitions- osse ei so tele See Seal le Gea 22 
50° The dotldStatrve Group Definitions sises ds eed ad PA eect 28 
546 Traps “For use Dy- BELAGES: reoaine e a ea Bg wes 31 
Gt Acknöwlédgments 26.6 eee ees So ot oie theca ela sie baie Io ace) E E 31 
Pe RELSTONCE Ss ada raa Greenery E 6 ied wed) Sande ona Sty Ue ae ios Seabed) sealer cao 33 
83 “Security Cóonsiderätions sost bebe tee eee is bach bee Bae eek 33 
9s Authors” Addresses weiss aa aa a ace oe eee elas ene a a Ble Send 34 
1. The Network Management Framework 


The Internet-standard Network Management Framework consists of three 
components. They are: 


STD16/RFC 1155 which defines the SMI, the mechanisms used for 
describing and naming objects for the purpose of management. 
STD16/RFC 1212 defines a more concise description mechanism, which 
is wholly consistent with the SMI. 


RFC 1156 which defines MIB-I, the core set of managed objects for 
the Internet suite of protocols. STD17/RFC 1213, defines MIB-II, 
an evolution of MIB-I based on implementation experience and new 
operational requirements. 


STD15/RFC 1157 which defines the SNMP, the protocol used for 
network access to managed objects. 


The Framework permits new objects to be defined for the purpose of 
experimentation and evaluation. 


2. Objects 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. Objects in the MIB are 
defined using the subset of Abstract Syntax Notation One (ASN.1) [7] 
defined in the SMI. In particular, each object is named by an OBJECT 
IDENTIFIER, an administratively assigned name, which specifies an 
object type. The object type together with an object instance serves 
to uniquely identify a specific instantiation of the object. For 
human convenience, we often use a textual string, termed the 
descriptor, to also refer to the object type. 
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Format of Definitions 


Section 5 contains the specification of all object types contained in 
this MIB module. The object types are defined using the conventions 
defined in the SMI, as amended by the extensions specified in [9,10]. 


Overview 


A common device present in many networks is the Bridge. This device 
is used to connect Local Area Network segments below the network 
layer. 


There are two major modes defined for this bridging; transparent and 
source route. The transparent method of bridging is defined in the 
draft IEEE 802.1d specification [11]. This memo defines those 
objects needed for the management of a bridging entity operating in 
the transparent mode, as well as some objects applicable to all types 
of bridges. 


To be consistent with IAB directives and good engineering practice, 

an explicit attempt was made to keep this MIB as simple as possible. 
This was accomplished by applying the following criteria to objects 

proposed for inclusion: 


(1) Start with a small set of essential objects and add only 
as further objects are needed. 


(2) Require objects be essential for either fault or 
configuration management. 


(3) Consider evidence of current use and/or utility. 
(4) Limit the total of objects. 


(5) Exclude objects which are simply derivable from others in 
this or other MIBs. 


(6) Avoid causing critical sections to be heavily 
instrumented. The guideline that was followed is one 
counter per critical section per layer. 


Structure of MIB 
Objects in this MIB are arranged into groups. Each group is 
organized as a set of related objects. The overall structure and 


assignment of objects to their groups is shown below. Where 
appropriate the corresponding IEEE 802.1d [11] management object name 
is also included. 
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Bridge MIB Name 


dotidBridge 
dotlidBase 


BridgeAddress 

NumPorts 

Type 

PortTable 
Port 
IfIndex 
Circuit 
DelayExceededDiscards 
MtuExceededDiscards 


dotldstp 


ProtocolSpecification 
Priority 


TimeSinceTopologyChange 
TopChanges 
DesignatedRoot 
RootCost 
RootPort 
MaxAge 
HelloTime 
HoldTime 
ForwardDelay 
BridgeMaxAge 
BridgeHelloTime 
BridgeForwardDelay 
PortTable 

Port 


Priority 

State 

Enable 

PathCost 
DesignatedRoot 
DesignatedCost 
DesignatedBridge 
DesignatedPort 
ForwardTransitions 


dotidTp 


LearnedEntryDiscards 


AgingTime 

FdbTable 
Address 
Port 
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IEEE 802.1d Name 


Bridge.BridgeAddress 
Bridge.NumberOfPorts 


BridgePort.PortNumber 


.DiscardTransitDelay 
.DiscardOnError 


SpanningTreeProtocol 
-BridgePriority 
. TimeSinceTopologyChange 
. TopologyChangeCount 
-DesignatedRoot 
-RootCost 
-RootPort 
.-MaxAge 
.-HelloTime 
- HoldTime 
-ForwardDelay 
.BridgeMaxAge 
-BridgeHelloTime 
.BridgeForwardDelay 


SpanningTreeProtocolPort 
-PortNumber 
-PortPriority 
. SpanningTreeState 


-PortPathCost 
.DesignatedRoot 
.DesignatedCost 
.DesignatedBridge 
.DesignatedPort 


BridgeFilter.DatabaseSize 
-NumDynamic,NumStatic 
BridgeFilter.AgingTime 
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Status 
PortTable 
Port 
MaxInfo 
InFrames 
OutFrames 
InDiscards 
dotidStatic 
StaticTable 
Address 
ReceivePort 
AllowedToGoTo 
Status 


July 1993 


BridgePort.FramesReceived 
.ForwardOutbound 
.-DiscardInbound 


The following IEEE 802.1d management objects have not been included 
in the Bridge MIB for the indicated reasons. 


TEEE 802.1d Object 


Bridge.BridgeName 
Bridge.BridgeUpTime 
Bridge.PortAddresses 
BridgePort.PortName 
BridgePort.PortType 
BridgePort .RoutingType 


SpanningTreeProtocol 
-BridgeIdentifier 
. TopologyChange 
SpanningTreeProtocolPort 
. Uptime 
-PortIdentifier 


. TopologyChangeAcknowledged 


-DiscardLackOfBuffers 


Transmission Priority 


.TransmissionPriorityName 
-OutboundUserPriority 
-OutboundAccessPriority 
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Disposition 


Same as sysDescr (MIB II) 

Same as sysUpTime (MIB IT) 
Same as ifPhysAddress (MIB IT) 
Same as ifDescr (MIB IT) 

Same as ifType (MIB ITI) 
Derivable from the implemented 
groups 


Combination of dotlidStpPriority 
and dotldBaseBridgeAddress 
Since this is transitory, it 

is not considered useful. 


Same as ifLastChange (MIB II) 
Combination of dotldStpPort 
and dotlidStpPortPriority 
Since this is transitory, it 
is not considered useful. 
Redundant 


These objects are not required 


as per the Pics Proforma and 
not considered useful. 
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3.1.1. The dotlidBase Group 


This mandatory group contains the objects which are applicable to all 
types of bridges. 


3.1.2. The dotldStp Group 


This group contains the objects that denote the bridge’s state with 


respect to the Spanning Tree Protocol. If a node does not 
implemented the Spanning Tree Protocol, this group will not be 
implemented. 


3.1.3. The dotldSr Group 


This group contains the objects that describe the entity’s state with 


respect to source route bridging. If source routing is not supported 
this group will not be implemented. This group is applicable to 
source route only, and SRT bridges. This group will be described in 


a separate document applicable only to source route bridging. 


3.1.4. The dotldTp Group 


This group contains objects that describe the entity’s state with 
respect to transparent bridging. If transparent bridging is not 
supported this group will not be implemented. This group is 
applicable to transparent only and SRT bridges. 


3.1.5. The dotlidStatic Group 


This group contains objects that describe the entity’s state with 
respect to destination-address filtering. If destination-address 
filtering is not supported this group will not be implemented. This 
group is applicable to any type of bridge which performs 
destination-address filtering. 


3.2. Relationship to Other MIBs 


As described above, some IEEE 802.1d management objects have not been 
included in this MIB because they overlap with objects in other MIBs 
applicable to a bridge implementing this MIB. In particular, it is 
assumed that a bridge implementing this MIB will also implement (at 
least) the ’system’ group and the ’interfaces’ group defined in MIB- 
TE [6]: 


3.2.1. Relationship to the ’system’ group 


In MIB-II, the ’system’ group is defined as being mandatory for all 
systems such that each managed entity contains one instance of each 
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object in the ’system’ group. Thus, those objects apply to the 
entity as a whole irrespective of whether the entity’s sole 
functionality is bridging, or whether bridging is only a subset of 
the entity’s functionality. 


3.2.2. Relationship to the ’interfaces’ group 


In MIB-II, the ‘interfaces’ group is defined as being mandatory for 
all systems and contains information on an entity’s interfaces, where 
each interface is thought of as being attached to a ‘subnetwork’. 
(Note that this term is not to be confused with ‘subnet’ which refers 
to an addressing partitioning scheme used in the Internet suite of 
protocols.) The term ’segment’ is used in this memo to refer to such 
a subnetwork, whether it be an Ethernet segment, a ’ring’, a WAN 
link, or even an X.25 virtual circuit. 


Implicit in this Bridge MIB is the notion of ports on a bridge. Each 
of these ports is associated with one interface of the ’interfaces’ 
group, and in most situations, each port is associated with a 
different interface. However, there are situations in which multiple 
ports are associated with the same interface. An example of such a 
situation would be several ports each corresponding one-to-one with 
several X.25 virtual circuits but all on the same interface. 


Each port is uniquely identified by a port number. A port number has 
no mandatory relationship to an interface number, but in the simple 
case a port number will have the same value as the corresponding 
interface’s interface number. Port numbers are in the range 
(1..dotldBaseNumPorts). 


Some entities perform other functionality as well as bridging through 
the sending and receiving of data on their interfaces. In such 
situations, only a subset of the data sent/received on an interface 
is within the domain of the entity’s bridging functionality. This 
subset is considered to be delineated according to a set of 
protocols, with some protocols being bridged, and other protocols not 
being bridged. For example, in an entity which exclusively performed 
bridging, all protocols would be considered as being bridged, whereas 
in an entity which performed IP routing on IP datagrams and only 
bridged other protocols, only the non-IP data would be considered as 
being bridged. 


Thus, this Bridge MIB (and in particular, its counters) are 
applicable only to that subset of the data on an entity’s interfaces 
which is sent/received for a protocol being bridged. All such data 
is sent/received via the ports of the bridge. 
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3.3. Textual Conventions 


The datatypes, MacAddress, BridgeId and Timeout, are used as textual 
conventions in this document. These textual conventions have NO 
effect on either the syntax nor the semantics of any managed object. 
Objects defined using these conventions are always encoded by means 
of the rules that define their primitive type. Hence, no changes to 
the SMI or the SNMP are necessary to accommodate these textual 
conventions which are adopted merely for the convenience of readers. 


4. Changes from RFC 1286 


(1) Updated all text to remove references to source route 
bridging where not applicable. SR MIB will be a separate 
document. 


(2) Removed dotidSrPortTable. Retained OID definition of 
dotidSr. 


(3) Updated all references of "draft P802.1d/D9" to "IEEE 
802.1D-1990". 


(4) Updated bibliography. 
(5) Added clarification to description of dotldPortPathCost. 


(6) Put recommended default in description of 
dotidStaticAllowedToGoTo. 


(7) Put recommended default in description of 
dotidStaticStatus. 
(8) Put recommended default in description of 


dotldTpAgingTime. Specified range of (10..1000000). 


(9) Updated all port number syntaxes, when used as index, to 
use the range (1..65535). 


(10) Updated definition of dotlidTpPortInFrames and 
dotldTpPortOutFrames. 


(11) Added text to the traps indicating that they are 
optional. 


(12) Clarified definition of dotldStpForwardDelay. 
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5. Definitions 
BRIDGE-MIB DEFINITIONS ::= BEGIN 


IMPORTS 

Counter, TimeTicks 

FROM RFC1155-SMI 
mib-2 

FROM RFC1213-MIB 
OBJECT-TYPE 

FROM RFC-1212 
TRAP-TYPE 

FROM RFC-1215; 


-- All representations of MAC addresses in this MIB Module 
-—- use, as a textual convention (i.e. this convention does 
-—- not affect their encoding), the data type: 


MacAddress ::= OCTET STRING (SIZE (6)) -- a 6 octet address 
—-- in the 
-—- "canonical" 
-- order 

—- defined by IEEE 802.1la, i.e., as if it were transmitted 

-—- least significant bit first, even though 802.5 (in 

-- contrast to other n802.x protocols) requires MAC 

-- addresses to be transmitted most significant bit first. 


—-- 16-bit addresses, if needed, are represented by setting 
—-- their upper 4 octets to all 0’s, i.e., AAFF would be 
-- represented as 00000000AAFF. 


-—- Similarly, all representations of Bridge-Id in this MIB 
-- Module use, as a textual convention (i.e. this 
-—- convention does not affect their encoding), the data 


=> type: 


BridgeId ::= OCTET STRING (SIZE (8)) -- the 
-- Bridge-Identifier 
-- as used in the 
-- Spanning Tree 
-- Protocol to uniquely identify a bridge. Its first two 
—-- octets (in network byte order) contain a priority 
-- value and its last 6 octets contain the MAC address 
-- used to refer to a bridge in a unique fashion 
—- (typically, the numerically smallest MAC address 
-- of all ports on the bridge). 
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Several objects in this MIB module represent values of 
timers used by the Spanning Tree Protocol. In this 
MIB, these timers have values in units of hundreths of 
a second (i.e. 1/100 secs). 

These timers, when stored in a Spanning Tree Protocol’s 
BPDU, are in units of 1/256 seconds. Note, however, 
that 802.1D-1990 specifies a settable granularity of 

no more than 1 second for these timers. To avoid 
ambiguity, a data type is defined here as a textual 
convention and all representation of these timers 

in this MIB module are defined using this data type. An 
algorithm is also defined for converting between the 
different units, to ensure a timer’s value is not 
distorted by multiple conversions. 

The data type is: 


Timeout ::= INTEGER -- a STP timer in units of 1/100 seconds 


-—- To convert a Timeout value into a value in units of 
-- 1/256 seconds, the following algorithm should be used: 


b = floor( (n * 256) / 100) 


where: 
floor = quotient [ignore remainder] 
n is the value in 1/100 second units 
b is the value in 1/256 second units 


To convert the value from 1/256 second units back to 
1/100 seconds, the following algorithm should be used: 


n = ceiling( (b * 100) / 256) 


where: 
ceiling = quotient [if remainder is 0], or 
quotient + 1 [if remainder is non-zero] 
n is the value in 1/100 second units 
b is the value in 1/256 second units 


Note: it is important that the arithmetic operations are 


done in the order specified (i.e., multiply first, divide 
second). 


dotidBridge OBJECT IDENTIFIER ::= { mib-2 17 } 
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-- groups in the Bridge MIB 


dotldBase OBJECT IDENTIFIER 
dotldstp OBJECT IDENTIFIER 
dotlidsSr OBJECT IDENTIFIER 
-—- separately documented 

dotldTp OBJECT IDENTIFIER 


dotidStatic OBJECT IDENTIFIER 


-- the dotildBase group 


dotidBridge 
dotidBridge 


dotidBridge 


dotidBridge 


dotidBridge 


July 1993 


—- Implementation of the dotldBase group is mandatory for all 


—- bridges. 


dotidBaseBridgeAddress OBJECT-TYPE 


SYNTAX MacAddress 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The MAC address used by this bridge when it must 
be referred to in a unique fashion. 
recommended that this be the numerically smallest 
MAC address of all ports that belong to this 
bridge. However it is only required to be unique. 
When concatenated with dotldStpPriority a unique 
BridgeIdentifier is formed which is used in the 


Spanning Tree Protocol." 


REFERENCE 


It is 


"IEEE 802.1D-1990: Sections 6.4.1.1.3 and 3.12.5" 


::= { dotldBase 1 } 


dotldBaseNumPorts OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 


"The number of ports controlled by this bridging 


entity." 
REFERENCE 


"IEEE 802.1D-1990: Section 6.4.1.1.3" 


::= { dotldBase 2 } 


dotldBaseType OBJECT-TYPE 


Decker, Langille, Rijsinghani & McCloghrie 


[Page 11] 


RFC 1493 Bridge MIB July 1993 


SYNTAX INTEGER { 
unknown (1), 
transparent-—only (2), 
sourceroute-only (3), 
srt (4) 
} 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 
"Indicates what type of bridging this bridge can 
perform. If a bridge is actually performing a 
certain type of bridging this will be indicated by 
entries in the port table for the given type." 
::= { dotldBase 3 } 


-—- The Generic Bridge Port Table 


dotldBasePortTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotldBasePortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A table that contains generic information about 
every port that is associated with this bridge. 
Transparent, source-route, and srt ports are 
included." 

::= { dotldBase 4 } 


dotidBasePortEntry OBJECT-TYPE 

SYNTAX DotldBasePortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A list of information for each port of the 
bridge." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.4.2, 6.6.1" 

INDEX { dotlidBasePort } 

::= { dotldBasePortTable 1 } 


DotldBasePortEntry ::= 
SEQUENCE { 
dotlidBasePort 
INTEGER, 
dotldBasePortIfiIndex 
INTEGER, 
dotlidBasePortCircuit 
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OBJECT IDENTIFIER, 
dotlidBasePortDelayExceededDiscards 
Counter, 
dotldBasePortMtuExceededDiscards 
Counter 


} 


dotlidBasePort OBJECT-TYPE 

SYNTAX INTEGER (1..65535) 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The port number of the port for which this entry 
contains bridge management information." 

:= { dotldBasePortEntry 1 } 


dotlidBasePortIfIndex OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The value of the instance of the ifIndex object, 
defined in MIB-II, for the interface corresponding 
to this port." 

::= { dotldBasePortEntry 2 } 


dotidBasePortCircuit OBJECT-TYPE 

SYNTAX OBJECT IDENTIFIER 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"For a port which (potentially) has the same value 
of dotldBasePortIfIndex as another port on the 
same bridge, this object contains the name of an 
object instance unique to this port. For example, 
in the case where multiple ports correspond one- 
to-one with multiple X.25 virtual circuits, this 
value might identify an (e.g., the first) object 
instance associated with the X.25 virtual circuit 
corresponding to this port. 


For a port which has a unique value of 
dotidBasePortIfIndex, this object can have the 
value { 0 0 }." 

:= { dotldBasePortEntry 3 } 


dotlidBasePortDelayExceededDiscards OBJECT-TYPE 
SYNTAX Counter 
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ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The number of frames discarded by this port due 
to excessive transit delay through the bridge. It 


is incremented by both transparent and source 
route bridges." 
REFERENCE 
"IEEE 802.1D-1990: Section 6.6.1.1.3" 
::= { dotldBasePortEntry 4 } 


dotldBasePortMtuExceededDiscards OBJECT-TYPE 
SYNTAX Counter 
ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The number of frames discarded by this port due 
to an excessive size. It is incremented by both 
transparent and source route bridges." 

REFERENCE 


"IEEE 802.1D-1990: Section 6.6.1.1.3" 
:= { dotldBasePortEntry 5 } 


-- the dotldStp group 


-—- Implementation of the dotldStp group is optional. It is 
-—- implemented by those bridges that support the Spanning Tree 
== Protocol. 


dotldStpProtocolSpecification OBJECT-TYPE 
SYNTAX INTEGER { 
unknown (1), 
decLb100(2), 
ieee8021d(3) 
} 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 
"An indication of what version of the Spanning 
Tree Protocol is being run. The value 
'decLb100(2)’ indicates the DEC LANbridge 100 
Spanning Tree protocol. IEEE 802.1d 
implementations will return ’ieee8021d(3)’. If 
future versions of the IEEE Spanning Tree Protocol 
are released that are incompatible with the 
current version a new value will be defined." 
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::= { dotldStp 1 } 


dotlidStpPriority OBJECT-TYPE 

SYNTAX INTEGER (0..65535) 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"The value of the write-able portion of the Bridge 
ID, i.e., the first two octets of the (8 octet 
long) Bridge ID. The other (last) 6 octets of the 
Bridge ID are given by the value of 
dotidBaseBridgeAddress." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.7" 

:= { dotldStp 2 } 


dotldStpTimeSinceTopologyChange OBJECT-TYPE 

SYNTAX TimeTicks 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The time (in hundredths of a second) since the 
last time a topology change was detected by the 
bridge entity." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.8.1.1.3" 

::= { dotldStp 3 } 


dotldStpTopChanges OBJECT-TYPE 

SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The total number of topology changes detected by 
this bridge since the management entity was last 
reset or initialized." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.8.1.1.3" 

::= { dotldStp 4 } 


dotldStpDesignatedRoot OBJECT-TYPE 

SYNTAX BridgelId 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The bridge identifier of the root of the spanning 
tree as determined by the Spanning Tree Protocol 
as executed by this node. This value is used as 
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the Root Identifier parameter in all Configuration 
Bridge PDUs originated by this node." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.1" 

::= { dotldStp 5 } 


dotldStpRootCost OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The cost of the path to the root as seen from 
this bridge." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.2" 

::= { dotldStp 6 } 


dotldStpRootPort OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The port number of the port which offers the 


lowest cost path from this bridge to the root 
bridge." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.3" 

::= { dotldStp 7 } 


dotldStpMaxAge OBJECT-TYPE 
SYNTAX Timeout 
ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The maximum age of Spanning Tree Protocol 


information learned from the network on any port 
before it is discarded, in units of hundredths of 
a second. This is the actual value that this 
bridge is currently using." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.4" 

::= { dotldStp 8 } 


dotlidStpHelloTime OBJECT-TYPE 
SYNTAX Timeout 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 
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"The amount of time between the transmission of 
Configuration bridge PDUs by this node on any port 
when it is the root of the spanning tree or trying 
to become so, in units of hundredths of a second. 
This is the actual value that this bridge is 
currently using." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.5" 

::= { dotldStp 9 } 


dotldStpHoldTime OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"This time value determines the interval length 
during which no more than two Configuration bridge 
PDUs shall be transmitted by this node, in units 
of hundredths of a second." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.14" 

:= { dotldStp 10 } 


dotlidStpForwardDelay OBJECT-TYPE 

SYNTAX Timeout 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"This time value, measured in units of hundredths 
of a second, controls how fast a port changes its 
spanning state when moving towards the Forwarding 


state. The value determines how long the port 
stays in each of the Listening and Learning 
states, which precede the Forwarding state. This 


value is also used, when a topology change has 
been detected and is underway, to age all dynamic 
entries in the Forwarding Database. [Note that 
this value is the one that this bridge is 
currently using, in contrast to 
dotldStpBridgeForwardDelay which is the value that 
this bridge and all others would start using 
if/when this bridge were to become the root.]" 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.6" 

:= { dotldStp 11 } 


dotldStpBridgeMaxAge OBJECT-TYPE 
SYNTAX Timeout (600..4000) 
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ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"The value that all bridges use for MaxAge when 
this bridge is acting as the root. Note that 
802.1D-1990 specifies that the range for this 
parameter is related to the value of 
dotlidStpBridgeHelloTime. The granularity of this 
timer is specified by 802.1D-1990 to be 1 second. 
An agent may return a badValue error if a set is 
attempted to a value which is not a whole number 
of seconds." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.8" 

:= { dotldStp 12 } 


dotldStpBridgeHelloTime OBJECT-TYPE 
SYNTAX Timeout (100..1000) 
ACCESS read-write 
STATUS mandatory 


DESCRIPTION 
"The value that all bridges use for HelloTime when 
this bridge is acting as the root. The 


granularity of this timer is specified by 802.1D- 
1990 to be 1 second. An agent may return a 
badValue error if a set is attempted to a value 
which is not a whole number of seconds." 
REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.9" 
:= { dotldStp 13 } 


dotldStpBridgeForwardDelay OBJECT-TYPE 

SYNTAX Timeout (400..3000) 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"The value that all bridges use for ForwardDelay 
when this bridge is acting as the root. Note that 
802.1D-1990 specifies that the range for this 
parameter is related to the value of 
dotldStpBridgeMaxAge. The granularity of this 
timer is specified by 802.1D-1990 to be 1 second. 
An agent may return a badValue error if a set is 
attempted to a value which is not a whole number 
of seconds." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.3.10" 

::= { dotldStp 14 } 


Decker, Langille, Rijsinghani & McCloghrie [Page 18] 


RFC 1493 Bridge MIB July 1993 


-- The Spanning Tree Port Table 


dotldStpPortTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotldStpPortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A table that contains port-specific information 
for the Spanning Tree Protocol." 

::= { dotldStp 15 } 


dotlidStpPortEntry OBJECT-TYPE 

SYNTAX DotidStpPortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A list of information maintained by every port 
about the Spanning Tree Protocol state for that 
port." 

INDEX { dotlidStpPort } 

::= { dotldStpPortTable 1 } 


DotldStpPortEntry ::= 
SEQUENCE { 
dotlidStpPort 
INTEGER, 
dotldStpPortPriority 
INTEGER, 
dotldStpPortState 
INTEGER, 
dotldStpPortEnable 
INTEGER, 
dotldStpPortPathCost 
INTEGER, 
dotldStpPortDesignatedRoot 
Bridgeld, 
dotldStpPortDesignatedCost 
INTEGER, 
dotldStpPortDesignatedBridge 
Bridgeld, 
dotldStpPortDesignatedPort 
OCTET STRING, 
dotldStpPortForwardTransitions 
Counter 


} 


dotlidStpPort OBJECT-TYPE 
SYNTAX INTEGER (1..65535) 
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ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The port number of the port for which this entry 
contains Spanning Tree Protocol management 
information." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.8.2.1.2" 

::= { dotlidStpPortEntry 1 } 


dotlidStpPortPriority OBJECT-TYPE 

SYNTAX INTEGER (0..255) 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"The value of the priority field which is 
contained in the first (in network byte order) 
octet of the (2 octet long) Port ID. The other 
octet of the Port ID is given by the value of 
dotlidsStpPort." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.5.1" 

::= { dotldStpPortEntry 2 } 


dotldStpPortState OBJECT-TYPE 
SYNTAX INTEGER { 

disabled(1 

blocking (2 

listening ( 

learning (4), 

forwarding(5), 
broken (6) 


r 


) 
y 
3), 
) 


} 
ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The port’s current state as defined by 
application of the Spanning Tree Protocol. This 
state controls what action a port takes on 
reception of a frame. If the bridge has detected 


a port that is malfunctioning it will place that 
port into the broken(6) state. For ports which 
are disabled (see dotldStpPortEnable), this object 
will have a value of disabled(1)." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.5.2" 

::= { dotldStpPortEntry 3 } 
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dotlidStpPortEnable OBJECT-TYPE 
SYNTAX INTEGER { 
enabled(1), 
disabled (2) 
} 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 
"The enabled/disabled status of the port." 
REFERENCE 
"IEEE 802.1D-1990: Section 4.5.5.2" 
::= { dotlidStpPortEntry 4 } 


dotldStpPortPathCost OBJECT-TYPE 

SYNTAX INTEGER (1..65535) 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"The contribution of this port to the path cost of 
paths towards the spanning tree root which include 
this port. 802.1D-1990 recommends that the 
default value of this parameter be in inverse 
proportion to the speed of the attached LAN." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.5.3" 

::= { dotldStpPortEntry 5 } 


dotldStpPortDesignatedRoot OBJECT-TYPE 

SYNTAX BridgeId 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The unique Bridge Identifier of the Bridge 
recorded as the Root in the Configuration BPDUs 
transmitted by the Designated Bridge for the 
segment to which the port is attached." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.5.4" 

::= { dotldStpPortEntry 6 } 


dotldStpPortDesignatedCost OBJECT-TYPE 
SYNTAX INTEGER 
ACCESS read-only 
STATUS mandatory 


DESCRIPTION 
"The path cost of the Designated Port of the 
segment connected to this port. This value is 


compared to the Root Path Cost field in received 
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bridge PDUs." 
REFERENCE 

"IEEE 802.1D-1990: Section 4.5.5.5" 
::= { dotldStpPortEntry 7 } 


dotldStpPortDesignatedBridge OBJECT-TYPE 

SYNTAX BridgelId 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The Bridge Identifier of the bridge which this 
port considers to be the Designated Bridge for 
this port’s segment." 

REFERENCE 
"IEEE 802.1D-1990: Section 4.5.5.6" 

::= { dotldStpPortEntry 8 } 


dotldStpPortDesignatedPort OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (2)) 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The Port Identifier of the port on the Designated 
Bridge for this port’s segment." 

REFERENCE 
"TEEE 802.1D-1990: Section 4.5.5.7" 

::= { dotldStpPortEntry 9 } 


dotlidStpPortForwardTransitions OBJECT-TYPE 

SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The number of times this port has transitioned 
from the Learning state to the Forwarding state." 

::= { dotldStpPortEntry 10 } 


-- the dotldTp group 
—- Implementation of the dotldTp group is optional. It is 
—- implemented by those bridges that support the transparent 


-—- bridging mode. A transparent or SRT bridge will implement 
-—- this group. 


dotldTpLearnedEntryDiscards OBJECT-TYPE 
SYNTAX Counter 
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ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The total number of Forwarding Database entries, 
which have been or would have been learnt, but 
have been discarded due to a lack of space to 
store them in the Forwarding Database. If this 
counter is increasing, it indicates that the 
Forwarding Database is regularly becoming full (a 
condition which has unpleasant performance effects 
on the subnetwork). If this counter has a 
significant value but is not presently increasing, 
it indicates that the problem has been occurring 
but is not persistent." 

REFERENCE 
"TEEE 802.1D-1990: Section 6.7.1.1.3" 

::= { dotldTp 1 } 


dotldTpAgingTime OBJECT-TYPE 

SYNTAX INTEGER (10..1000000) 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"The timeout period in seconds for aging out 
dynamically learned forwarding information. 
802.1D-1990 recommends a default of 300 seconds." 

REFERENCE 
"TEEE 802.1D-1990: Section 6.7.1.1.3" 

:= { dotldTp 2 } 


-—- The Forwarding Database for Transparent Bridges 


dotldTpFdbTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotldTpFdbEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A table that contains information about unicast 
entries for which the bridge has forwarding and/or 
filtering information. This information is used 
by the transparent bridging function in 
determining how to propagate a received frame." 

:= { dotldTp 3 } 


dotldTpFdbEntry OBJECT-TYPE 


SYNTAX DotldTpFdbEntry 
ACCESS not-accessible 
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STATUS mandatory 
DESCRIPTION 
"Information about a specific unicast MAC address 
for which the bridge has some forwarding and/or 
filtering information." 
INDEX { dotldTpFdbAddress } 
:= { dotldTpFdbTable 1 } 


DotldTpFdbEntry ::= 
SEQUENCE { 
dotldTpFdbAddress 
MacAddress, 
dotldTpFdbPort 
INTEGER, 
dotldTpFdbStatus 
INTEGER 


} 


dotldTpFdbAddress OBJECT-TYPE 

SYNTAX MacAddress 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"A unicast MAC address for which the bridge has 
forwarding and/or filtering information." 

REFERENCE 
"IEEE 802.1D-1990: Section 3.9.1, 3.9.2" 

::= { dotldTpFdbEntry 1 } 


dotldTpFdbPort OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"Either the value ’0’, or the port number of the 
port on which a frame having a source address 
equal to the value of the corresponding instance 
of dotldTpFdbAddress has been seen. A value of 
‘0’ indicates that the port number has not been 
learned but that the bridge does have some 
forwarding/filtering information about this 
address (e.g. in the dotldStaticTable). 
Implementors are encouraged to assign the port 
value to this object whenever it is learned even 
for addresses for which the corresponding value of 
dotldTpFdbStatus is not learned(3)." 

::= { dotldTpFdbEntry 2 } 
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dotldTpFdbStatus OBJECT-TYPE 


SYNTAX INTEGER { 
other (1) 
invalid 
learned 
self (4), 
mgmt (5) 

} 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 


"The status of this entry. 


values are: 


other (1) 


invalid(2) 


learned (3) 


self (4) 


mgmt (5) 


( 
( 


The meanings of the 


none of the following. This would 
include the case where some other 
MIB object (not the corresponding 
instance of dotldTpFdbPort, nor an 
entry in the dotldStaticTable) is 
being used to determine if and how 
frames addressed to the value of 
the corresponding instance of 
dotldTpFdbAddress are being 
forwarded. 


this entry is not longer valid 
(e.g., it was learned but has since 
aged-out), but has not yet been 
flushed from the table. 


the value of the corresponding 
instance of dotldTpFdbPort was 
learned, and is being used. 


the value of the corresponding 
instance of dotldTpFdbAddress 
represents one of the bridge’s 
addresses. The corresponding 
instance of dotldTpFdbPort 
indicates which of the bridge’s 
ports has this address. 


the value of the corresponding 
instance of dotldTpFdbAddress is 
also the value of an existing 
instance of dotldStaticAddress." 


::= { dotldTpFdbEntry 3 } 
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-—- Port Table for Transparent Bridges 


dotldTpPortTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotldTpPortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A table that contains information about every 
port that is associated with this transparent 
bridge." 

::= { dotldTp 4 } 


dotldTpPortEntry OBJECT-TYPE 

SYNTAX DotildTpPortEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A list of information for each port of a 
transparent bridge." 

INDEX { dotldTpPort } 

::= { dotldTpPortTable 1 } 


DotldTpPortEntry ::= 
SEQUENCE { 
dotldTpPort 
INTEGER, 
dotldTpPortMaxInfo 
INTEGER, 
dotldTpPortInFrames 
Counter, 
dotldTpPortOutFrames 
Counter, 
dotldTpPortInDiscards 
Counter 


} 


dotldTpPort OBJECT-TYPE 

SYNTAX INTEGER (1..65535) 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The port number of the port for which this entry 
contains Transparent bridging management 
information." 

:= { dotldTpPortEntry 1 } 


-- It would be nice if we could use ifMtu as the size of the 
-—- largest INFO field, but we can’t because ifMtu is defined 
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-- to be the size that the (inter-)network layer can use which 
-- can differ from the MAC layer (especially if several layers 
-—- of encapsulation are used). 


dotldTpPortMaxInfo OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The maximum size of the INFO (non-MAC) field that 
this port will receive or transmit." 

::= { dotldTpPortEntry 2 } 


dotldTpPortInFrames OBJECT-TYPE 

SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The number of frames that have been received by 
this port from its segment. Note that a frame 
received on the interface corresponding to this 
port is only counted by this object if and only if 
it is for a protocol being processed by the local 
bridging function, including bridge management 
frames." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.6.1.1.3" 

::= { dotldTpPortEntry 3 } 


dotldTpPortOutFrames OBJECT-TYPE 

SYNTAX Counter 

ACCESS read-only 

STATUS mandatory 

DESCRIPTION 
"The number of frames that have been transmitted 
by this port to its segment. Note that a frame 
transmitted on the interface corresponding to this 
port is only counted by this object if and only if 
it is for a protocol being processed by the local 
bridging function, including bridge management 
frames." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.6.1.1.3" 

:= { dotldTpPortEntry 4 } 


dotldTpPortInDiscards OBJECT-TYPE 
SYNTAX Counter 
ACCESS read-only 
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STATUS mandatory 

DESCRIPTION 
"Count of valid frames received which were 
discarded (i.e., filtered) by the Forwarding 
Process." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.6.1.1.3" 

:= { dotldTpPortEntry 5 } 


-—- The Static (Destination-Address Filtering) Database 


-—- Implementation of this group is optional. 


dotidStaticTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DotldStaticEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"A table containing filtering information 
configured into the bridge by (local or network) 
management specifying the set of ports to which 
frames received from specific ports and containing 
specific destination addresses are allowed to be 
forwarded. The value of zero in this table as the 
port number from which frames with a specific 
destination address are received, is used to 
specify all ports for which there is no specific 
entry in this table for that particular 


destination address. Entries are valid for 
unicast and for group/broadcast addresses." 
REFERENCE 


"IEEE 802.1D-1990: Section 6.7.2" 
::= { dotldStatic 1 } 


dotidStaticEntry OBJECT-TYPE 

SYNTAX DotildStaticEntry 

ACCESS not-accessible 

STATUS mandatory 

DESCRIPTION 
"Filtering information configured into the bridge 
by (local or network) management specifying the 
set of ports to which frames received from a 
specific port and containing a specific 
destination address are allowed to be forwarded." 

REFERENCE 
"IEEE 802.1D-1990: Section 6.7.2" 
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INDEX { dotidStaticAddress, dotidStaticReceivePort } 
::= { dotldStaticTable 1 } 


DotildStaticEntry ::= 
SEQUENCE { 
dotlidStaticAddress 
MacAddress, 
dotildStaticReceivePort 
INTEGER, 
dotidStaticAllowedToGoTo 
OCTET STRING, 
dotidStaticStatus 
INTEGER 
} 


dotidStaticAddress OBJECT-TYPE 
SYNTAX MacAddress 
ACCESS read-write 
STATUS mandatory 


DESCRIPTION 
"The destination MAC address in a frame to which 
this entry’s filtering information applies. This 


object can take the value of a unicast address, a 
group address or the broadcast address." 
REFERENCE 
"IEEE 802.1D-1990: Section 3.9.1, 3.9.2" 
::= { dotldStaticEntry 1 } 


dotidStaticReceivePort OBJECT-TYPE 

SYNTAX INTEGER 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 
"Either the value ’0’, or the port number of the 
port from which a frame must be received in order 
for this entry’s filtering information to apply. 
A value of zero indicates that this entry applies 
on all ports of the bridge for which there is no 
other applicable entry." 

::= { dotldStaticEntry 2 } 


dotlidStaticAllowedToGoTo OBJECT-TYPE 
SYNTAX OCTET STRING 
ACCESS read-write 
STATUS mandatory 
DESCRIPTION 
"The set of ports to which frames received from a 
specific port and destined for a specific MAC 
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address, are allowed to be forwarded. Each octet 
within the value of this object specifies a set of 
eight ports, with the first octet specifying ports 
1 through 8, the second octet specifying ports 9 
through 16, etc. Within each octet, the most 
significant bit represents the lowest numbered 
port, and the least significant bit represents the 
highest numbered port. Thus, each port of the 
bridge is represented by a single bit within the 
value of this object. If that bit has a value of 
‘1’ then that port is included in the set of 
ports; the port is not included if its bit has a 
value of ’0’. (Note that the setting of the bit 
corresponding to the port from which a frame is 
received is irrelevant.) The default value of 
this object is a string of ones of appropriate 
length." 


{ dotlidStaticEntry 3 } 


dotidStaticStatus OBJECT-TYPE 


SYNTAX INTEGER { 
other (1), 
invalid(2), 
permanent (3), 
deleteOnReset (4), 
deleteOnTimeout (5) 

} 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 


Langille, 


"This object indicates the status of this entry. 
The default value is permanent (3). 


other(1) - this entry is currently in use but 
the conditions under which it will 
remain so are different from each of the 
following values. 


invalid(2) - writing this value to the object 
removes the corresponding entry. 
permanent (3) - this entry is currently in use 


and will remain so after the next reset 
of the bridge. 

deleteOnReset (4) - this entry is currently in 
use and will remain so until the next 
reset of the bridge. 


deleteOnTimeout (5) - this entry is currently 
in use and will remain so until it is 
aged out." 
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::= { dotldStaticEntry 4 } 


—- Traps for use by Bridges 
-- Traps for the Spanning Tree Protocol 


newRoot TRAP-TYPE 

ENTERPRISE dotldBridge 

DESCRIPTION 
"The newRoot trap indicates that the sending agent 
has become the new root of the Spanning Tree; the 
trap is sent by a bridge soon after its election 
as the new root, e.g., upon expiration of the 
Topology Change Timer immediately subsequent to 
its election. Implementation of this trap is 
optional." 


topologyChange TRAP-TYPE 

ENTERPRISE dotldBridge 

DESCRIPTION 
"A topologyChange trap is sent by a bridge when 
any of its configured ports transitions from the 
Learning state to the Forwarding state, or from 
the Forwarding state to the Blocking state. The 
trap is not sent if a newRoot trap is sent for the 
same transition. Implementation of this trap is 
optional." 


END 
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